\subsection{Extensions to the mechanism of verifying a file}
\label{sec:mechanism}

The limited or impossible prospect of a user-space program checking the integrity of a file can be alleviated somewhat by changing the workflow of verifying a file.  As discussed above, usually a file is checked and then some finite time passes before the file is opened.

Once a file is opened, the normal operating system protections prevent manipulation of the resolution of the resource.  Therefore the non-atomicity of the check-open process is the core vulnerability, so this should be eliminated.  Instead, if a file can be opened and thereby locked, and then checked, this would make the check atomic under the guise of the operating system protections.  This is conceptually simple, and precisely our modification here.

Rather than using a path to resolve a resource, a file descriptor for a file that is already locked can be passed to the Linux calls to read extended attributes.  These attributes will be used to validate the file, and this avoids altogether the TOCCTOU attack.

Even more, once a file is locked, the canonical path to the file can be resolved, preventing linked paths from obscuring the location of the file.  Therefore dependable canonicalizing of the path to a resource is also gained.
